Avionics systems typically have a variety of components that provide data to other components of the aircraft or exchange data among one or more other components of the aircraft. An avionics system typically includes multiple general purpose modules (GPMs), which are computers for general computing needs. Other computers are special purpose computers, such as line replaceable units (LRUs) and remote data concentrators (RDCs). For example, a variety of external sensors may gather information (e.g., speed, direction, external temperature, and the like) that is routed via an avionics network or databus to one or more aircraft components. The data from multiple sensors may be collected by a strategically located RDC and then sent to other avionics system components via the avionics network or databus. An RDC or LRU may also be used to send control signals to actuators and valves.
Components of an avionics system can be connected via an Ethernet type network through network switches. In an avionics network environment, the Ethernet network has various components (e.g., LRUs, RDCs) that form a publisher and subscriber relationship. Each network publisher can send packets in digital form, at controlled rates, to one or more subscribers. When a switch receives the packets, the switch determines the destination equipment and routes the packets to such equipment.
ARINC 664 Part 7 sets forth an aeronautical standard that defines a dual redundant avionics network for use in an aircraft environment and more specifically describes an Avionics Full DupleX (AFDX) switched Ethernet network. In a switched full-duplex Ethernet type network, the term “full-duplex” refers to sending and receiving packets at the same time on the same link, and the term “switched” refers to the packets being switched in switches on appropriate outputs. The AFDX network uses multiple switches and redundant paths to route data, point-to-point or point-to-multipoint across the switches. AFDX switches use store-and-forward technology. The AFDX network also includes end systems, which behave like conventional network interface cards that connect system components like LRUs, RDCs, and GPMs to the network media
Aircraft subsystems can communicate with each other over an AFDX network using virtual links. Each virtual link defines a particular routing of information in the AFDX network. In particular, a virtual link defines the data source and its destinations. Each virtual link can have a defined bandwidth set by its transmission frequency and its packet's maximum payload size. An AFDX end system may implement a number of virtual links for transmission of data and also defines other virtual links as a receiver. Multiple aircraft subsystems can be grouped physically and connected to the AFDX network by end systems.
The Boeing 787 program has vendors who supply hardware and tools (platform suppliers) and suppliers who provide software applications (hosted function suppliers) for its avionics system comprising a multiplicity of subsystems (i.e., computers) connected by a network. Avionics interfaces of the types previously described can also be used to instrument all of the parameters of the various subsystems and electronically collect this data for presentation to the flight crew for use in flying the aircraft. To facilitate data transmission across the network, the various subsystems must be properly configured. These subsystems have all their configuration parameters and data stored inside an Interface Configuration Database (ICD) in XML file format. These XML files define how each component of the avionics system is connected and configured, how the data (and what kind of data) flows from one end of the system to another, how various devices in the system interact with each other, and the transmission and receiving rates for each message going through the network, etc.
More specifically, the ICD contains all the data and parameters (several hundred thousand) for configuration of airplane avionics systems. These data and parameters define how components on the airplane communicate with each other (protocol), dictate rate/frequency at which they initiate and respond to communication protocols, and allocate in which computing node a particular application program resides, to name just a few. Since each node hosts multiple applications, the ICD also stipulates where in a computer node's memory space each application should stay. All these data and parameters are entered into the ICD manually by engineers.
The system platform suppliers and hosted function suppliers depend upon the aforementioned ICD parameters and data for configuration so that all hardware and software components can work and function together smoothly when all of them bring their modules to the airplane for Boeing to conduct final system integration and assembly. However, there has been no easy and reliable way to verify and validate that those hundreds of thousands of parameters and data in the ICD were entered correctly or that their complicated dependency structures were defined accurately. Traditionally this verification and validation process has been carried out manually, which is extremely labor intensive and error prone. Many engineers, with pencil and paper, can spend days to ensure that what they have entered into the ICD is correct and accurate. When any changes or modifications occur in the ICD, which happens frequently during the initial engineering stage of the airplane development, they can cause a ripple effect across the system. Very often the engineers are forced to make profound changes in both the component and system level configuration files and the laborious manual checking process must be repeated to mitigate any undesirable ramifications.
Furthermore, when one hosted function supplier comes in for system testing and integration, its software application must be running in a functioning avionics system where the hosted function can check its application behavior, performance and characteristics. Currently the avionics system for the Boeing 787 airplane may have 60 plus hosted function applications. When the first couple of hosted function vendors show up for system testing and integration, there will be no running avionics system because to drive data flow as per ICD configuration requires hosted function applications. This presents a classic “chicken or the egg” dilemma—to verify and validate the ICD configuration requires integrated and validated hosted function applications, but to integrate and validate the hosted function applications demands a validated ICD configuration.
There is a need for an automated method for verifying and validating configuration parameters and data of hosted function applications to be loaded into networked computers at the system level. There is a further need for a system that simulates the communications functions of hosted function applications to be run on a not yet fully functional networked computer system, for the purpose of enabling a hosted function supplier to plug in its application software for system level testing and integration.